手撕公司SSO登陆原理，看了都说好！
点击上方 "程序员小乐"关注, 星标或置顶一起成长
每天凌晨00点00分, 第一时间与你相约
每日英文
Never expect, never assume, and never demand. Just let it be, because if it's meant to be, it will happen the way you want it to.
永不期待，永不假设，永不强求。顺其自然，若是注定发生，必会如你所愿。
每日掏心话
人生最遗憾的莫过于：轻易地放弃了不该放弃的，固执地坚持了不该坚持的。。
来自：nodotnet | 责编：乐乐
链接：cnblogs.com/JulianHuang/p/11811239.html
程序员小乐(ID:study_tech)第 695 次推文 图片来自网络
往日回顾：滴滴程序员年薪80万却被亲戚鄙视：钱多有啥用，我儿子二本大学教师
正文
Single Sign-on
SSO是老生常谈的话题了，但部分同学对SSO可能掌握的也是云里雾里，一知半解。本次手撕公司的SSO原理，试图以一种简单，流畅的形式为你提供有用的SSO原理。
按照本人一贯行文风格，我们先说什么是SSO，为什么要提出SSO？
SSO：在多个系统中，只需要登陆一次，就可以访问其他相互信任的应用系统， 这个技术的提出解决了：
企业运行了多个服务，而账号需要集中统一管理
终端用户登陆一次，即可使用一个账户享受所有不同域名下服务。
SSO 与CAS（Central Authentication System）这个概念密切相关，账户集中由某个服务管理，SSO服务只负责登陆认证。
登陆认证与【服务端在浏览器上写入的认证Cookie】密切相关， Cookie 有一系列重要属性：Domain，Path， Expiration，HttpOnly 决定了该Cookie 在客户端的作用域、作用范围、有效时间、有效操作方式
原理
用户首次访问 website1
① 用户访问website1 系统，website1系统需要认证， 用户当前没有登陆
② website1给客户端返回302重定向响应， 客户端重定向到SSO服务页
# 交互过程确实是临时跳转，下面传参false， 返回302临时重定向响应
context.Response.Redirect(ssoURL, false);
用户并没有登陆SSO系统，所以SSO系统会返回登陆界面
③ 用户在SSO登陆界面输出账户/密码
④ 登陆成功，SSO会在客户端写入一个 cookie for sso并产生一个301重定向响应，客户端将重定向到原website1地址，该请求附带了SSO给与这次认证成功的 ticket
http://www.website1.com?ticket=XXXX-OOOO-XXXX-OOOO
⑤ website1收到以上重定向请求，解析QueryString中的ticket， 向SSO做一次ticket验证；验证通过向客户端写入本站的 cookie for website
⑥ 上面第5步，浏览器地址会显示：http://www.website1.com?ticket=XXXX-OOOO-XXXX-OOOO， 在本站验证通过之后，最好再做一个重定向，返回业务首页：www.website1.com， 本步骤不是SSO登陆的标准流程。
之后用户访问website2
① 用户访问website2， 用户在website2并没得到认证；跳转回 SSO
② SSO服务检测到该 用户在SSO域下存在Cookie for sso， 认定该用户已经登陆，故跳转回website2， 如上也会携带认证ticket
③ 如上，website2收到 website2.com?ticket=XXXX-OOOO-XXXX-OOOO请求， 会做一次SSO验证；验证成功，写入本站cookie for website2
重难点解读
① SSO认证成功，写入的cookie for sso， 是登陆到其他系统的关键
② website1收到SSO发起的重定向请求，解析出ticket=XXXX-OOOO-XXXX-OOOO， 为什么还要做一次SSO验证？
因为website1收到的带ticket请求，有可能是伪造， 所以在website1中需要去SSO验证一次。
③ 标准的CAS登陆流程有两次302客户端重定向， 分别由原站点website1和SSO启动。
理论上 整个流程由服务端重定向也是可以的 ？？看官若发现有漏洞，可在评论区回复。
④ 退出SSO登陆， 要做两件事情：
- 向SSO发起api请求，请求SSO删除用户在SSO域下的认证cookie for sso
- 移除本站的cookie for website1
⑤ 每个website，至少需要如下sso配置
"SsoOptions": { "BaseAddress": "https://sso-cas.sso.com", // 基地址 "LoginPath": "/login", // sso登陆地址 "LogoutPath": "/api/logout", // 退出sso登陆的api地址 "ValidateTGTPath": "/api/validate", // 验证ticket的api地址 "UserInfoPath": "/api/v2/userinfo" // 从sso拿到登陆用户信息的api地址 },
That' all，这是自己对SSO登陆的一些理解， 本图文希望以流畅的思路记录SSO流程， 各位看官不要吃快餐，知其然更知其所以然很关键。
欢迎在留言区留下你的观点，一起讨论提高。如果今天的文章让你有新的启发，学习能力的提升上有新的认识，欢迎转发分享给更多人。
欢迎各位读者加入程序员小乐技术群，在公众号后台回复“加群”或者“学习”即可。
猜你还想看
Spring Boot & Restful API 构建实战